fix(runtime): retry worker and widget-dev cleanup with the promise form of rm - #631

Fixes #626. Refs #563, #622.

Why

On Windows, rmSync(path, { recursive: true, force: true, maxRetries }) reports a held directory as EBUSY (Node 22) or EPERM (Node 24) at once and never runs its retries. #622 measured this, and it reproduces here (Windows 11, Node v24.11.0): with a child process holding the directory as its working directory, rmSync(..., { maxRetries: 5, retryDelay: 100 }) threw EPERM after 0 ms, while await rm(...) from node:fs/promises with the same options removed it after 637 ms, once the holder let go 300 ms in.

Two production call sites relied on the broken retry:

What changes

• Worker run directory. runWorkerProcess is already async, so its finally now awaits rm. A failure is still swallowed as before (the directory holds the brief, never a key). The run's result or error now waits for cleanup: at most about 1.5 s, and only while the directory is held.
• Widget-dev snapshots. prune becomes async, and both callers await it. Both callers (follow and activate) are already async, and they run only on the session's serial chain, so nothing else of that session interleaves with the removal. A snapshot that still cannot be removed after the retries stays on the session's list and is tried again after the next install, as before.
  • The retry budget goes from 2 attempts (about 0.3 s, which never ran) to 5 attempts with retryDelay: 100 (about 1.5 s), the same as the worker. The wait now lands on one session's chain, not on the event loop.
• No exit-handler or synchronous caller is involved. Neither site runs inside a process exit handler, and no synchronous caller had to become async. createWidgetDevSessions().close() does not wait for the chains today, and it still does not.
• This uses rm from node:fs/promises directly, as task-browser.ts and package-fetch.ts already do. No new helper is added.

Tests

apps/runtime/test/hold-directory.ts is a new helper. It holds a directory by running a child process with that directory as its working directory, and it reports when the hold is really in place. On Windows, that makes removal fail with EBUSY or EPERM until the child exits. On other platforms the hold changes nothing, so the tests pass there but only tell the two forms apart on Windows.

Each spec wraps rmSync and rm so that it can see when the removal starts, without changing what the removal does. It releases the hold 300 ms later. Only a removal that really retries finds the directory free.

• worker-process.spec.ts: removes its run directory even when the directory is still held for a moment after the worker exits. The hold starts when the run directory is made, and the test asserts that the hold was in place when the removal started, so it cannot pass without proving anything.
• widget-dev-sessions.spec.ts: removes a superseded snapshot that is held for a moment, as a file still open on Windows holds it. The first build's snapshot is held. The second build keeps it as the rollback target, and the third prunes it. The snapshot must be gone, and off the session's list.

Both new tests fail against main's source (Windows 11, Node v24.11.0). Each was run with only the source file reverted to origin/main. Each fails at expect(existsSync(...)).toBe(false), because the directory is still there.

Verification (Windows 11, Node v24.11.0)

Overlap with open PRs

• test: remove spec directories with the retrying async helper, since rmSync never retries on Windows #622 (test: rmSync maxRetries never retries on Windows; move spec cleanup to the async retrying helper #563) is open. It owns tools/invariants/test-cleanup-retries-asynchronously.mjs, which this PR does not touch. The two PRs do not change the same files. The new specs here use rmSync without maxRetries (in the specs' own wrappers and in the worker test's final cleanup), so they do not trip test: remove spec directories with the retrying async helper, since rmSync never retries on Windows #622's invariant. Extending that invariant (or a sibling) to production code, as fix(runtime): production cleanup uses rmSync with maxRetries, which never retries on Windows #626 suggests, can follow once test: remove spec directories with the retrying async helper, since rmSync never retries on Windows #622 lands, since no production site would fail it after this PR.
• fix(widgets): re-arm a dev session on a changed folder id and bound persistent stat errors #614 and feat(widgets): let the person choose a project folder for widget dev sessions #612 both change apps/runtime/src/application/widget-dev-sessions.ts and apps/runtime/test/widget-dev-sessions.spec.ts. This PR touches only prune, its two call sites, the node:fs mock at the top of the spec, and one new test after the existing prune test. Whichever lands second may need a small textual rebase.

Overlap correction

#622 also edits apps/runtime/test/widget-dev-sessions.spec.ts. A trial merge conflicts on one import line only; keeping both imports passes invariants (15/15) and the affected specs. Whichever of #612 or #614 lands after this PR must keep await prune(...) at both call sites, because lint does not flag floating promises.